home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19970929-19971216
/
000058_news@newsmaster….columbia.edu _Tue Oct 7 01:40:29 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-12-15
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id BAA15739
for <kermit.misc@watsun.cc.columbia.edu>; Tue, 7 Oct 1997 01:39:06 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id BAA17369
for kermit.misc@watsun; Tue, 7 Oct 1997 01:39:06 -0400 (EDT)
Path: news.columbia.edu!news.cloud9.net!news-out.internetmci.com!newsfeed.internetmci.com!164.67.42.145!nntp.info.ucla.edu!134.87.113.1!news.bc.net!rover.ucs.ualberta.ca!alberta!not-for-mail
From: Vladimir Alexiev <vladimir@cs.ualberta.ca>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit via PPP under DOS?
Date: 06 Oct 1997 19:30:11 -0600
Organization: University of Alberta, Computing Science
Lines: 76
Message-ID: <omvhza9x7g.fsf@tees.cs.ualberta.ca>
References: <k1c7kBQEU5Wv@cc.usu.edu> <omraa16rl3.fsf@tees.cs.ualberta.ca>
<4TpKBo0duVW2@cc.usu.edu>
NNTP-Posting-Host: tees.cs.ualberta.ca
In-reply-to: jrd@cc.usu.edu's message of 5 Oct 97 08:40:36 MDT
X-Newsreader: Gnus v5.0.15
Xref: news.columbia.edu comp.protocols.kermit.misc:7829
In article <4TpKBo0duVW2@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
Joe, the discussion is getting unnecessarily antagonistic, and I would hate
that. I understand very well that you're the driving force behind MS Kermit,
and I'm very grateful for what you've done for it. But I think that making it
work with emulated class 1 (if possible and feasible) would make it slightly
better. Of course, it should be first determined whether this is really a
desideratum (that's why I asked what are the benefits of class 1, if any), and
whether the effort required is worth it. Now, I know squat about TCP stacks,
but I have this gut feeling (whatever that's worth) that it is something
pretty small that prevents Kermit from doing it. After all, all the required
functionality for class 1 is thre, and all the required functionality for
serial line drivers is there.
If you decide such a task is worth pursuing, I'm offering my help with testing
and experiments, and if you prefer, we can switch this discussion offline.
> Class 1 Packet Drivers have no identification with "Internet"; we
> presume that's your name for IP packets.
Sorry, it's a typo, I meant Ethernet.
> Again here are fundamentals and I hope you pause to understand this.
> A Packet Driver advertisizing itself as Ethernet (Class 1) on the top tells
> the application protocol stack that Ethernet is the lan topology and hence
> Ethernet rules apply.
Right. Something often used in the Unix world is "proxy ARPing". In that case
a gateway host G that's connected to an ethernet and further to the internet,
serves as a proxy to a client C that's connected to D through a PPP link. When
another host X from G's ethernet ARPs with the IP of C, G returns its own MAC,
and then takes care to forward any packets received as a result of that fake
to C. (see eg http://www.med2000.com:457/NetAdminG/pppC.proxy_arp.html)
I don't know how do EPPPD and PPP -k 1 emulate class 1, but I suppose it's
somethign similar.
> Amongst them are supporting MAC addresses, identifying stations in the same
> broadcast domain
Proxy ARPing makes C appear to be connected to G's ethernet.
> Frame construction is only part of the situation.
It is my understanding that class 1 emulators do take care of ARP issues.
> If a PPP or carrier-pigeon or whatever driver advertisizes itself
> as Ethernet to the protocol stack then it must emulate Ethernet
> characteristics to the protocol stack.
Which ethernet characteristics do those emulators fail to emulate, and are
they critical for the operation of a telnet application?
> I have not the slightest idea of what code is in those programs.
> Have you looked at them to see what they do internally?
No. I was hoping that we could determine what is the problem by looking at
Kermit "from the outside" and/or by using some packet analyzers.
> > if one would like to use another TCP app together with Kermit, that app
> > should also support class 6
> We do not support any attempt to run two TCP/IP stacks over the same
> lan driver, period. Folks may be succussful at times with pktmux...
Consider this: a user may want to first run telnet, then close Kermit down and
read their email using the same PPP connection. This is impossible if the
telnet and the mail reader don't use the same driver class.
> > You seem to assert that class 1 emulating serial drivers are impossible,
> No such assertion has been made by me. You are the guy going to
> extremes.
Ok, maybe I chose my words wrong, but what you've written so far is:
- class 1 is supposed to work this way: <a non-technical description>
- Kermit works ok with real class 1
- ergo, there must be something wrong with class 1 emulators
Of course, what I wrote isn't more technical either:
- these other apps work with class 1 emulators
- ergo, it should be easy to change Kermit to also work with them
> >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
dosppp class 6 doesn't support it. How about MeritPPP class 6?